雲端運算-期末考
第七章
- 雲端作業系統與傳統作業系統間的本質差異
- 企業使用
- 雲端比傳統擁有龐大的硬體後援，比自行架設伺服器具高延展性與穩定性
- 主機成本負擔
- 傳統OS運作於伺服器，雲端OS透過Internet進行資料傳輸與運算
- 資料保存
- 儲存於雲端平台提供的資料庫，透過雲端服務公司的日常維護工作異地備援的特性
- OpenStack的優勢
- OpenStack被譽為繼Linux之後最成功的開源組織
- OpenStack九大功能套件，舉三個套件說明其功用
第十一章
- 雲端在科學研究的應用說明/特性
- IaaS
- 透過IaaS，使用者可以向服務提供者租用所需的硬體設備
- 彈性地依據目前實驗需求動態調整租用電腦主機的數量及效能
- PaaS
- 使用者可依據自身欲開發之科學應用或服務功能，向提供PaaS廠商租賃平台
- 透過平台即服務的好處是可減少維護管理系統底層的成本
- 一個環節出錯即可能造成資料庫的帳號密碼等重要資訊全曝光，使得敏感資料暴露在危險當中
- 而租用雲端平台，便可由雲端公司代管，在維護或管理上相對更穩定
- SaaS
- 科學研究的應用上，使用者可依照自身對科學應用服務之需求，向提供軟體即服務廠商租賃相關應用軟體來使用
- 科學應用繪圖程式 (OriginPro, SigmaPlot, etc.)
- 數學方程式運算程式 (Microsoft Math, ILP, SMT/OMT Solvers)
- 使用者可藉由網際網路直接使用該應用程式，而不需掌控該軟體之架構
- 雲端在生物科學研究的應用依照不同廠商、研究單位之需求提供安全的使用環境、高速的運算機能、大量的儲存機能，以及寬頻優質的網路環境，同時可藉由雲端運算節省大量採購設備與維護的經費。
- 雲端在企業資訊發展的應用
- IaaS
- 依照自身欲開發之企業資訊相關內容，向提供IaaS廠商租賃設備包含基礎伺服器、網路資料庫等設備及軟體整合
- 系統面，透過IaaS，企業可專注於營運相關的核心作業，不必再擔心系統相容性與擴充的問題
- 業務成長做彈性及快速的擴充，加快企業導入時程，滿足企業降低營運成本及彈性提升系統效能的雙向需求
- 成本面，企業無須採購昂貴的硬體設備，即可以月租的方式取得所需運算、儲存、作業系統等資源，有效降低企業持有成本與維運成本
- PaaS
- 隨著雲端服務的發展，企業產生各種不同類型的雲端服務，因而需要進行企業內部的系統整合，PaaS逐漸擴展為提供各種服務整合中介的平台
- 就企業資訊發展於PaaS而言，可提供使用者在應用程式開發、部署、整合與中介等平台服務
- PaaS也支援自動化的備份機制和災後回復，使企業不必擔心系統錯誤的發生
- SaaS
- SaaS廠商開發了各種支援管理的資訊工具如搜尋引擎、企業入口網站、內部網路、資料探勘、文件管理系統程式等
- 企業可透過租賃該軟體，以處理大量企業內部資料，為企業提供更有效率的運作環境
- 企業管理工具通常所費不貲，造成企業管理在IT工具應用上的困難
- 在實際的案例上，世大化成公司向中華電信流通雲租賃「金賺錢雲端POS服務」，透過中華電信的雲端科技，解決了內部缺乏MIS專業人員建置及維護雲端POS系統的困擾
- 隨時掌握櫃點的銷售狀況及庫存量，所有商品價格及折扣透過系統控管，可有效降低門市人員負擔
- 若遇到缺貨情況，櫃點人員也可直接透過雲端POS系統直接調貨，不僅省時、省力，還省下電話費
第十二章
- 雲端的安全風險
- 傳統的安全威脅 (從傳統到雲端的變化)、攻擊手法等
- 大量的雲端資源和使用者，使得傳統的安全威脅更加嚴重
- 使用者在連到雲端時，必須保護基礎建設，與雲端執行的應用程式互動 → 相當困難
- 認證程序威脅：每個人必須基於組織中的角色，而被設定不同的權限，無法將目前企業內部的資安策略直接運用到雲端上
- 傳統攻擊包括
- 分散式阻斷攻擊 (Distributed Denial of Service, DDoS)
- 釣魚程式 (Phishing) → 竊取個人隱私資訊
- SQL的置入 (Injection) → 利用SQL語法漏洞以竊取資料庫權限
- 跨網描述攻擊 (Cross-Site Scripting) → 騙使用者轉到一些惡意的網站 → 透過Script來獲得使用者隱私資訊
- 系統可用性的威脅 (數位鑑識)
- 在多使用者的環境下，虛擬機管理器的弱點，可能讓惡意的使用者有新的攻擊管道
- 傳統基於數位鑑識(Digital Forensics)的辨識方法無法直接運用在雲端上
- 因雲端中的資源是由許多使用者共用，在各種儲存媒體上有大量的寫入運算 → 沒有個人的專屬硬體/軟體設備概念
- 當系統損壞、電力損壞或其他的災害發生，雲端的服務將會停止一段時間，此時企業將無法使用雲端服務
- 另一個可用性的議題是使用者將應用程式放在雲端中執行
- 無法確認是否回傳正確的結果 → 中途是否被竄改的可能?
- 協力廠商資料控制的威脅
- 協力廠商的控制由於缺乏透明性和限制使用者的控制產生許多的問題
- 雲端供應商的資源是來自於協力廠商，但是協力廠商的可信度是一大問題
- 協力廠商間接與雲端供應商簽約，因而提供不良的儲存設備，以至於遺失了資料
- 另外一個困難，如何證明使用者刪掉的資料確實在雲端中被刪除
- 因缺乏透明性的緣故，故在雲端中稽核是一件非常困難的事
- 要實現稽核功能需大量的成本 (儲存空間與頻寬等問題)
- 使用者對欲採用的IT雲端公司架構需重點特別注意
- 資訊安全組織
- 建立一個管理架構，用於公司內部資訊安全的管理和控制，以及執行現有的資訊安全規定
- 資產管理
- 針對組織各項資產(軟硬體與資訊等)的安全進行有效保護
- 通訊與作業管理
- 盡可能完善公司內外的溝通聯繫，以利於資訊安全管理系統的順利運行
- 雲端伺服器攻擊手法
- 分散式阻斷服務攻擊（Distributed Denial of Service, DDoS）
- 駭客利用大量殭屍電腦同時攻擊，達到妨礙正常使用者使用服務的目的
- 中間人攻擊（Man-in-the-Middle Attack）
- 駭客扮演中間人角色，假冒伺服器端接收到傳送的訊息，再假冒使用者端把訊息傳給真正的伺服器主機，藉此方式可在兩端連線不知情的情況下竊取或變更傳遞的訊息內容
- 系統漏洞攻擊（System Vulnerability Attack）
- 利用已發現或未公開的系統弱點進行攻擊，取得或提升服務主機(Windows、Unix-like、SQL )管理權限
- SaaS提供身分辨識管理和登入服務
- 在傳統IT佈署在企業內的模式
- 企業的敏感資料因實體、邏輯、個人安全和存取的政策，階放在企業內部
- 在SaaS的模式中，企業的資料儲存在企業的外部，也就是SaaS的供應商
- 對於應用程式安全的弱點或惡意的員工，SaaS的提供者必須採用額外的安全機制確保資料安全和避免被盜取
- 資料的安全上使用較強的加密技術和較好的認證去控制存取資料
- 如企業中如果需要EC2的管理者去使用主機，則需使用較強的加密方法SSH去存取
- 儲存在S3的資料，預設是不加密的，使用者將他們的資料上傳前可先加密，其他未授權的人就無法存取
- 純粹的身份管理：只處理帳號的建立、管理和刪除而不處理存取的部分
- 使用者的登入管理：使用者可以使用帳號、晶片信用卡、指紋等當作登入的方式
- CSA提出雲端運算七大安全威脅
- 濫用或利用雲端運算進行非法的行為
- 通常並不會要求使用者必須經過嚴格的資料審查過程，就可直接使用雲端所提供的資源，有些服務供應商甚至提供免費使用的功能或試用期
- 容易成為有心分子利用的管道，已經有包含殭屍網路、木馬程式下載在內的惡意程式運行於雲端運算的系統內
- 不安全的介面與APIs
- 介面與API是否安全直接影響到雲端運算服務本身的安全性
- 像使用者介面的驗證與授權功能是否安全，API的相依性與安全性
- 如果有使用第三方的加值服務，這些服務的介面與API的安全性也必須一併加以考量
- 惡意的內部人員(Malicious Insiders)
- 使用者無法得知雲端運算服務供應商如何規範與管理內部員工，甚至連招聘的條件與流程也屬於非公開的資訊
- 以雲端運算的業務性質而言，絕對是有心分子眼中的肥羊，所以內部惡意員工的比例應當會比一般組織來的更高
- 共享環境所造成的議題
- 使用者好像擁有獨立的環境，但是這些環境都是從共享的實體環境中透過虛擬化的技術所產生出來的
- 虛擬化的平台能否將不同的使用者進行有效地隔離，以避免彼此之間相互干擾其服務的正常運算，甚至是避免彼此之間可存取對方的資源
- 資料遺失或外洩
- 對於一個組織的影響不只在於實際上的金錢損失，更在於如企業形象之類的無形損失
- 是否擁有足夠的AAA (驗證、授權、稽核)、是否採用適當且足夠的加密技術、資料持續性的需求、如何安全地刪除資料、災難復原、甚至是司法管轄的問題
- 帳號或服務被竊取
- 雲端運算沒有實體的東西，因此一旦帳號或服務被竊取後，惡意分子可完全取代原先使用者的身分
- 傳統的IT環境中，因為使用者至少還擁有硬體的控制權，所以即使發生帳號或服務的竊取行為，使用者還是可進行一些事後的補救措施，但這些補救措施在雲端運算的架構下可能無法執行
- 對於那些公開的雲端運算服務而言，直接暴露於網際網路上也讓這些竊取行為更加容易發生
- 未知的風險模型
- 以雲端運算來說，不管是IaaS、PaaS、SaaS都是將服務包裝成一個使用者不需了解也無法了解的系統，讓使用者專注於如何「使用」該系統
- 但是這樣的方便性，也讓使用者無法了解這些服務所使用的網路架構、安全架構、軟體版本等各式各樣的重要資訊，這些資訊對於評估安全狀態是很有幫助的
第十三章
- 傳統資料中心的挑戰
- 超頻額率帶來的問題說明
- 超額率 (oversubscription) 伺服器的頻寬對所有上傳頻寬的比例
- 當網路流量從存取層移動到聚集層和核心層會造成
- 分享上傳頻寬的伺服器數量增加 → 導致超額率也增加並造成瓶頸
- 超額率限制了伺服器的容量，比例應該是1：1，如此主機才能使用他們全部的網路頻寬
- 由於超額率壅塞也會導致交換器的緩衝儲存器超載，而開始丟棄封包
- 基於TCP保證資料送達的機制，未能成功傳送資料的伺服器，會重新做資料傳送的動作，此時系統的吞吐量會急速降低，造成效能崩潰的現象，此種問題稱之為 TCP Incast (如：MapReduce應用)
- STP與路由分配不平均問題
- 一般資料中心網路的問題是缺乏容錯性
- 特別是在樹的上層，較少實體的網路連接線 → 在核心層或聚集層的硬體損壞會導致網路整體的效能快速下降
- 在網路第二層STP (Spanning Tree Protocol) 協定的機制，即使有多的路徑存在也只使用一條路徑，導致資源利用率非常低
- 避免造成迴圈 → 避免廣播風暴 → 取消某些可使用的連結 → 網路連結使用率下降
- 在核心層和聚集層由於流量不能平均分配到路徑上，所以也會產生負載平衡的問題
- 在資料中心執行的伺服器，動態分配資源是最佳的解決方式，將大部分的工作分配在30%的伺服器上執行，而其他未使用的伺服器可關機節省能源
- 交換器為主的資料中心架構特性
- Fat-tree 架構特性與可解決的傳統挑戰
- 交換器為主的資料中心架構主要是使用交換器來互相連接和資料的繞徑。著名的方法包括
- Fat-Tree的拓樸結構包括了k群(pod)，每群包含k/2個邊際交換器(Edge Switch)和k/2個聚集交換器
- 邊際交換器和聚集交換器連接成clos拓樸，在每群中形成完整二分圖(Completed Bipartite)，每一個群連接到所有的核心交換器，形成另一個二分圖
- Fat-Tree是每層由k-port相同的交換器所建構而成，每個交換器可以支援(k3/4)主機。Fat-Tree的IP定址為10:pod:subnet:hosted
- Fat-Tree架構主要是解決超額率(oversubscribe)、高成本的聚集和核心交換器、容錯、可規模化的問題
- 伺服器為主的資料中心架構特性
- DCell 架構特性與可解決的傳統挑戰
- 使用低成本的迷你交換器取代高成本的核心和聚集交換器
- DCell0是由n個伺服器連接到一個低成本較少port的迷你交換器所組成
- DCell1包含(n+1)個DCell0，每一個DCell0使用完全網線(Full mesh)的方式連接到其他每一個DCell0
- 在一般DCell拓樸中的每個伺服器有兩個網路介面 (即兩張網卡)
- (1) 一個連接至迷你交換器 (2) 一個連接到鄰居DCell0的伺服器
- 任意兩個伺服器具有[i, j-1]和[j, i]變數值，而且滿足每個i和j>i，都有一條連線連接
- 使用分散式容錯繞徑演算法的設計，所以在各種型態的錯誤下(例如：連線、伺服器、積架)，它有結構或拓樸的高容錯特性可避免
- 冷卻系統定義
- 三種空氣流動策略
- 部分圍護，採用空氣流動管理的技術，但是沒有完全隔離冷熱空氣之間的流動（使用冷熱過道）
- 虛擬化的威脅
- 網路服務在虛擬化環境中必須從實體機層延伸到較低的虛擬層
- 虛擬交換器和虛擬拓撲，對於資料中心網路拓撲帶來更多的複雜性
- 傳統的Three Tier拓撲結構，例如可成長到四或五層，在各種雲端環境中這可能是次優也是不切實際 → 效能下降
- MAC位址管理和虛擬機的擴展性是一個主要關注的議題，目的是避免網路設備中MAC表超載
第十四章
- 傳統網路架構與SDN網路架構之差異
- 傳統網路架構與SDN網路架構的主要差異在於控制層與資料層的分離
- 在傳統網路架構中，這兩層是緊密結合在一起的，這意味著網路設備，如交換機和路由器，同時負責資料轉發和路由決策。
- SDN架構中，控制層被抽象出來並集中化，使網路控制更加靈活和集中。這樣的設計允許更容易地實現網路的動態配置和管理，並可以透過軟體應用程序來快速適應不同的網路需求和條件。這對於網路管理和優化來說是一個顯著的改進。
- 傳統的網路面臨的挑戰
- 成本及效能
- 網路設備運算需求及硬體成本提高，而繁複的運算亦導致網路傳輸效能低落
- 網路管理者所需的彈性
- 此網路架構難以滿足雲端運算對硬體及網路進行虛擬化的基本需求
- 基礎建設層(Infrastructure Layer)
- OpenFlow網路架構
- 旨在透過開放式網路架構提高網路效能，滿足彈性的使用需求，並提供更精確的網路管理能力。這種架構將網路控制與硬體基礎設施分離，使網路設計和管理更加靈活和高效。
- 流表（Flow Table）管理：在OpenFlow網路中，交換器（Switches）不需要通過不斷學習來尋找封包傳送路徑。相反，它們根據由中央控制器設定的流表來轉發數據。這些流表指定了如何處理網路流量，例如“如果頭部（header）等於x，則發送到端口2”，或者“如果頭部等於y，則用z覆蓋頭部並發送到端口5和6”。
- 協定特性：OpenFlow協定允許網路的程式化，支持諸如負載平衡、頻寬管理、服務質量（QoS）保證、網路分離等功能。在這種架構中，數據轉發功能仍然留在交換器中，但決策功能則轉移到OpenFlow控制器。為了保證安全性，控制器與OpenFlow交換器之間需要建立一個秘密頻道（通常使用SSL加密技術），確保信息傳輸的安全性。
- Flow Table運作流程
- 控制器建立的封包的處理邏輯，會建立成Flow Table並更新至OpenFlow交換器
- 交換器依據資深的FlowTable即可快速將各類封包依據FlowTable決定其該採取的動作
- 修改部分內容 (Header field, tagging, etc.)
- 遇到未知封包時，交換器將其壓縮後轉送至控制器進一步處理